home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Light ROM 4
/
Light ROM 4 - Disc 1.iso
/
text
/
maillist
/
1994
/
oct94.doc
/
000052_owner-lightwave-l _Wed Oct 5 20:24:51 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1995-03-23
|
4KB
Return-Path: <owner-lightwave-l>
Received: by mail2.netcom.com (8.6.9/Netcom)
id SAA19291; Wed, 5 Oct 1994 18:43:42 -0700
Received: from dub-img-1.compuserve.com by mail2.netcom.com (8.6.9/Netcom)
id SAA19282; Wed, 5 Oct 1994 18:43:38 -0700
Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.940406sam)
id VAA05842; Wed, 5 Oct 1994 21:43:30 -0400
Date: 05 Oct 94 21:39:03 EDT
From: John Foust - Syndesis Corporation <76004.1763@compuserve.com>
To: LightWave <lightwave-l@netcom.com>
Subject: Re: LW World Tour
Message-ID: <941006013903_76004.1763_DHI67-1@CompuServe.COM>
Sender: owner-lightwave-l@netcom.com
Precedence: bulk
To: lightwave
bjorke@pixar.com (Kevin Bjorke) writes:
> Many progams can realize big performance wins by doing their own lower-
> level memory management -- an example that springs readily to mind is a
> database. It can be easily argued that programs like Layout are really
> databases. The renderer certainly uses lots of standardized packets. Should
> there be a malloc() call for each and every one? What about on the PowerPC?
> Should it be doing NewHandle() calls multiple times per pixel? Or grabbing
> purgeable chunks and monitoring them? The latter, certainly. It will use
> less memory that way, and spend less time doing it.
Amen. There's a product out there called SmartHeap, a replacement
for malloc/free. Their drop-in link library (available for Mac, PC,
SGI, etc.) works *orders of magnitude* improvements. It completely
saved InterChange for Windows' behind, because the malloc/free in
Microsoft's Visual C was so bad, malloc() would fail after several
thousand small allocations that totaled no more than 25K.
Give praise to AmigaDOS, from whose Exec many companies could learn
lessons. So if your favorite 3D program seems to take forever when
loading or clearing scenes, tell the developers about SmartHeap.
This is an unsolicited testimonial; it still irks me to spend $700 on
SmartHeap to fix a $200 compiler.
> > In any case, the 3.0 ASL file requester is better than any other one
> > I've ever seen, so its in my best interest if apps use it :-)
> Except that it will be hated by all the expert users on every other
> platform. Witness Playmation, universally (in the non-Amiga universe)
Yes, Windows has a "common dialog", but it's extensible in terms of
the developer being able to add extra buttons, but I've never heard
of it being replaceable like the Amiga file requesters.
A larger issue is that I've heard that LW for Windows user interface
was leveraged quickly by making Windows versions of the gadget and
menu routines used on the Amiga version. This may mean the interface
still has the "wall of buttons" approach, with real Windows buttons
but maybe some "fake" pop-up menus, perhaps.
Of course, PC users aren't as fussy as Amiga or Mac zealots.
PC users like programs like AutoCAD and 3D Studio, which have menus on
top, menus on the side, icon buttons, function key tricks, and
usually some kind of command line.
> PS: Anyone know about thrid-party products' plans to move cross-platform?
> Wavemaker? Newton's Law?
I suspect that any plug-in maker that's actually alive and shipping
product (I'd remove Newton's Law from that list, and add Positron
instead) is thinking of the port to any program that's extensible.
Porting a plug-in is usually pretty easy.
Wait till things heat up at the next Siggraph: when 3D Studio for
Windows NT hits the ground with IPAS plug-ins as Windows DLLs, when
Softimage for WinNT arrives, when Ray Dream for Windows arrives, when
a half-dozen other companies have announced or shipped plug-in
specs... and then plug-ins might become cross-product-friendly,
meaning they might plug into more than one program. Plug-ins have
come to re-define products themselves - for what would 3D Studio be,
if IPAS didn't exist?